Schematic capture is a well known process in computer aided engineering for converting a schematic drawing generated by a designer into a format which can be processed by a computer. Commercially available schematic capture software packages allow a designer to communicate the design to a computer without having to enter the design in a form cumbersome for the designer but readable by the computer. A schematic capture package typically converts the interconnected set of functional components to a net list (a list of components and interconnections between these components) which can be further manipulated by other computer programs to perform a design function desired by a designer.
One function for which schematic capture can be used is to program a field programmable logic array chip to perform the logic or arithmetic task indicated by the design. Another function is to simulate or verify the design and test it to determine whether the design will perform as the designer intended. Other functions are the synthesis of new design implementations from the original circuit design.
Typical schematic capture packages have included a library of primitive components, such as Boolean AND, XOR, flipflop, etc., which the designer may place onto a schematic diagram presented on a computer display and interconnect with lines to form a logic design. However, designers frequently think in terms of higher level logic/arithmetic functions to be performed, for example counters, adders, registers and multiplexers. Entering a design directly in terms of the higher level logic operations which the design is to perform is more convenient and intuitive for a designer than is entering the logic design in terms of primitive AND, flipflop gates, etc.
Data Type
Certain high level arithmetic functional components such as adder, register, and counter are frequently used. Related patent application Ser. No. 07/785,659, filed concurrently with the present application, entitled Generating Logic Modules for a High Level Digital Circuit Design, describes a method for implementing certain high level functional components directly input by a designer in a digital logic circuit without involving the intermediate step of generating primitive schematic diagrams. These high level functions typically operate on values of more than one digit, and the values are typically passed on buses. The bus width is preferably selected by the designer, in which case the bus width must be specified by the designer when entering the schematic design using high level components. Further, digital circuit designers use several data type conventions for performing computer math, for example analog, unsigned binary, signed binary, and 2's complement. A string of 1's and 0's has a different meaning for a 2's complement data type than for an unsigned binary data type. There are also non-arithmetic data types for representing characters and graphical images, for example. If data are generated in one part of a logic design in one data type and fed to another portion the logic design which expects and processes the data as another data type, an error will result or the data will be misinterpreted. Thus data types must be consistent or at least compatible.
Further, a bus for transferring data from one part of a computer to another or from one part of a single chip to another may be of a different width than another bus. (Here the word "bus" means a single line as well as a group of lines.) When a field programmable gate array chip is configured to perform an arithmetic function, the width of the bus must be specified by the software which configures the chip, and the width of a bus which will carry the output of a numeric calculation must be sufficient to carry the full precision of the number. For example, a bus which receives the sum output of a 16-bit adder must be 16 bits wide.
In general, it is important that the data types and bus widths be consistent or at least compatible throughout the design.
Prior art methods for programming a logic design into a chip which will implement the design have not included means for checking the data type for consistency. Designers who fail to design with consistency thus risk incurring errors in the design and may have to correct the design before it functions properly to achieve the desired result.
The only prior art methods for checking data type are those which distinguish between a single conductive line and a multi-line bus and check that the width of (number of conductors in) a bus are consistent--but not that the processing units are consistent in terms of data type. Those that do check have required the designer to enter data type at every node of the design, making the process extremely cumbersome.